Эдвард Йордон - Путь камикадзе [Смертельный марш]

Как правило, достаточно полная модель риска может включать сто или более факторов риска; как отмечено ранее, некоторые проектные команды сознательно ограничиваются рассмотрением десяти наиболее существенных рисков. Некоторые из рисков можно оценить количественно – например, требования к производительности (скорости реакции системы) или объём системы, выраженный в количестве функциональных точек. Другие факторы – например, степень дружелюбности или враждебности пользователей – могут быть оценены только качественно. Такие факторы принято характеризовать значениями «высокий», «низкий» или «средний».

После того, как риски подверглись идентификации и оценке, менеджер и команда могут попытаться выбрать подходящую стратегию минимизации или исключения по возможности большего количества рисков. Эта деятельность носит, конечно, общий характер, однако не следует забывать, что сама природа безнадёжного проекта такова, что количество рисков превышает обычное, они более серьёзны, и от них нельзя просто так избавиться. С другой стороны, если риски являются экстраординарными, то и решения должны быть адекватными: в то время как проектная команда «нормального» проекта может никогда не набраться смелости, чтобы обратиться к исполнительному директору или первому вице-президенту с просьбой уменьшить риск путём существенного увеличения бюджета или снятия серьёзных бюрократических ограничений, будет вполне разумным обратиться с такой просьбой в безнадёжном проекте. Если вы этого не сделаете – а для этого может потребоваться пройти по иерархической лестнице и обойти несколько уровней тупых начальников – то вы так никогда и не узнаете, удалось бы вам решить ваши проблемы или нет.

В любом случае, если существуют серьёзные факторы риска, воздействие которых исключить невозможно – а в безнадёжных проектах почти всегда так оно и есть – их следует зафиксировать в специальном документе, идентифицировав для каждого риска возможные последствия и разработав план действий в непредвиденных ситуациях. Это не будет чисто политическим «прикрытием задницы», поскольку в том случае, если риск материализуется и повлечёт за собой провал проекта, то последствия, как правило, будут печальными для всех, имеющих отношение к проекту; в конце концов, таковы реалии безнадёжных проектов. Тем не менее, отрицание реальности – также довольно распространённое явление в безнадёжных проектах. Как участники проектной команды, так и пользователи и руководители различных уровней зачастую страдают близорукостью и напрочь игнорируют существование серьёзных проектных рисков. Вполне можно ожидать, что менеджер проекта и участники команды будут с усердием уделять своё внимание «внутренним» рискам; однако, как было отмечено выше, участники команды зачастую оставляют без внимания «внешние» риски, поскольку они связаны с проблемами организации и бизнеса, неподвластными команде. Таким образом, документирование рисков является важной практической деятельностью, подталкивающей пользователей и руководство к пониманию того, что они предпочитали не замечать и игнорировать.

Довольно легко оставить за бортом многие из тех идей, которые обсуждались в этой главе, и оказаться впоследствии в плену пустопорожней бюрократии. Однако, как отмечает Stephen Nesbit (я получил его сообщение как раз тогда, когда добрался до конца этой главы и не знал толком, как её закончить):

Отсутствие стандартов и методологии само по себе может превратить проект в безнадёжный. Например, в моем последнем проекте сжатый и нереальный план был использован в качестве предлога для того, чтобы отказаться от следующего:

1) Использования системы конфигурационного управления для контроля проектного исходного кода, сосредоточенного в трех различных компьютерных системах, расположенных в двух территориально удалённых местах. В результате значительное время было потеряно впустую в попытках:

а) осуществить сборку программного обеспечения;

б) определить, кому какая версия ПО принадлежит;

в) определить, почему ПО работает на одной системе и не работает на другой.

2) Регистрации узких мест и дефектов с помощью системы конфигурационного управления. В результате стало совершенно невозможно оперативно выяснить, какие ошибки устраняются, а какие проигнорированы; какие компоненты закончены и могут тестироваться.

3) Документальной фиксации основных требований, проектных решений и вариантов, узловых точек в процессе разработки и используемых тестов. В результате участникам проектной команды оказалось чрезвычайно трудно добиться взаимопонимания не только относительно текущего состояния проекта, но также и относительно основных решений, принятых в самом начале проекта.

Итак, пожалуйста, не надо воспринимать эту главу как предлог для отказа от каких-либо процессов, методологий или методов вообще; в самом деле, это может погубить безнадёжный проект. Фокус заключается в том, чтобы отыскать те процессы, методологии или методы, которые действительно работают, и которым команда будет следовать естественным образом и бессознательно. Последнее особенно важно: команда испытывает такой стресс и давление, что должна делать многие вещи чисто инстинктивно. Если взвалить на команду бремя новых, незнакомых процессов, которые настолько сложны, что они вынуждены будут каждые пять минут останавливаться и заглядывать в руководство, чтобы определить, что делать дальше, то все пропадёт впустую. Поэтому надо поступать проще – и если команда может запомнить только одно слово, этим словом должно быть приоритетность.

Литература к главе:

1) Stephen R. Covey, Roger A. Merill, Rebecca R. Merill. First Things First. New York: Simon & Schuster, 1994.

2) Watts Humphrey. A Discipline of Software Engineering. Reading, MA: Addison-Wesley, 1995.

3) James Bach. The Challenge of ‘Good Enough’ Software. American Programmer, October 1995.

4) Jim McCarthy. Dynamics of Software Development. Redmond, WA: Microsoft Press, 1995.

5) G. Pascal Zachary. Show-Stopper! New York: Free Press, 1994.

6) Rob Thomsett. The Indiana Jones School of Risk Management. American Programmer, September 1992.

7) Capers Jones. Assessment and Control of Software Risks. Englewood Cliffs, NJ: Prentice Hall, 1994.

8) Rob Charette. Building Bridges over Intellectual Rivers. American Programmer, September 1992.

Дополнительная литература:

1) 1. Alan M. Davis. Software Requirements: Objects, Functions, and States. Englewood Cliffs, NJ: Prentice Hall, 1993.

2) Mark C. Paulk, Charles V. Weber, Bill Curtis, Mary Beth Chrises, et al. The Capability Maturity Model: Guidelines for Improving the Software Process. Reading, MA: Addison-Wesley, 1995.

3) Robert N. Charette. Application Strategies for Risk Analysis. New York: McGraw-Hill, 1990.

4) Robert N. Charette. Software Engineering Risk Analysis and Management. New York: McGraw-Hill, 1989.

Летом 1992 года мне довелось обедать с дружной группой менеджеров среднего уровня Microsoft. Во время завязавшейся беседы я спросил, является ли для проектных команд Microsoft обычным делом использование таких методологий, как структурный анализ или объектно-ориентированное проектирование. Ответы были примерно следующими: «иногда», «хммм, вроде бы да», «от случая к случаю» и «а что это такое?». Когда же я спросил их относительно использования CASE-средств (которые в то время все ещё были довольно популярными в индустрии ПО), то из их ответов понял, в чем заключается общее мнение майкрософтовцев: такие средства годятся для «людей с улицы». С таким выражением я ещё не встречался, его можно грубо интерпретировать как «невежественные дикари, которые только что вылезли из своего первобытного леса и начали обучаться программированию, в отличие от настоящих программистов, которые не нуждаются во всяких финтифлюшках».

Будучи слегка уязвлённым, я поинтересовался, используют ли их проектные команды хоть какие-нибудь средства, и в ответ услышал, что каждая команда Microsoft может выбрать любые средства, которые сочтёт подходящими для своего проекта. Ухватившись за такой ответ, я спросил, какое средство считает наиболее важным типичная проектная команда?

«На днях я задал одной из проектных команд такой же вопрос», – ответил один из менеджеров. «Как вы думаете, что они ответили?»

«Какой-нибудь высокопроизводительный компилятор С++?», – спросил я. «Ассемблер? Или мощное средство отладки для устранения множества ошибок в их коде (хи-хи-хи) ?»

«Ничего подобного», – ответил менеджер, игнорируя моё гнусное хихиканье. «Они ответили: электронная почта. Средний разработчик Microsoft получает сотню сообщений в день; он живёт в электронной почте. Уберите электронную почту, и проект умрёт».

Рассказывая этот анекдотический случай, я неспроста в самом начале упомянул 1992 год: эти события происходили до начала эры Internet и World Wide Web. Сотня почтовых сообщений в день потрясла моё воображение; в 1992 году я был безумно счастлив, если получал два или три сообщения в день. Однако можно представить себе, что если бы такой же вопрос о «наиболее важном средстве» был задан в 1996 году, ответом могло быть «World Wide Web»; по аналогии, «факс» в 1987, «ПК» в 1983, «онлайновый терминал» в 1976 и «мой собственный телефон на рабочем столе» в 1964 году, когда я только начинал свою карьеру программиста.